Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NTP SI: update default counts and reset to initial counts on SI data update, browser restart and every 24hr #19823

Merged
merged 5 commits into from
Sep 27, 2023

Conversation

petemill
Copy link
Member

@petemill petemill commented Aug 22, 2023

NTP SI count defaults updated to 1st view after install and every 3rd thereafter. Previously it was 2nd view after install and every 4th thereafter. In addition, the initial view count (now 1st) is used after browser restart and after the SI data gets updated. This avoids the problem of missing the SI data for the 1st pageview after install.

Lastly, the count gets reset to the "initial" value every 24 hours. This ensures a user is likely to see a multi-day campaign each day even if they open fewer NTPs than the regular count-to-branded-wallpaper.

Resolves brave/brave-browser#31551
Resolves brave/brave-browser#33228

Submitter Checklist:

  • I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
  • There is a ticket for my issue
  • Used Github auto-closing keywords in the PR description above
  • Wrote a good PR/commit description
  • Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
  • Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
  • Checked the PR locally:
    • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
    • npm run lint, npm run presubmit wiki, npm run gn_check, npm run tslint
  • Ran git rebase master (if needed)

Reviewer Checklist:

  • A security review is not needed, or a link to one is included in the PR description
  • New files have MPL-2.0 license header
  • Adequate test coverage exists to prevent regressions
  • Major classes, functions and non-trivial code blocks are well-commented
  • Changes in component dependencies are properly reflected in gn
  • Code follows the style guide
  • Test plan is specified in PR before merging

After-merge Checklist:

Test Plan:

@petemill petemill self-assigned this Aug 22, 2023
constexpr base::FeatureParam<int> kInitialCountToBrandedWallpaper{
&kBraveNTPBrandedWallpaper, "initial_count_to_branded_wallpaper", 1};
&kBraveNTPBrandedWallpaper, "initial_count_to_branded_wallpaper", 0};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend leaving the default value and testing this initial count via this Griffin feature

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The griffin value won't apply to first run. A restart is required. But seems we may separate first-run value from after-restart initial values.


// Show branded wallpaper every nth new tab page.
constexpr base::FeatureParam<int> kCountToBrandedWallpaper{
&kBraveNTPBrandedWallpaper, "count_to_branded_wallpaper", 3};
&kBraveNTPBrandedWallpaper, "count_to_branded_wallpaper", 2};
Copy link
Collaborator

@tmancey tmancey Aug 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend leaving the default value and testing this count via this Griffin feature

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we go to 2 I'm not sure I see us have the desire to go back to 3, since numbers would be worse and UX impact doesn't seem huge? Also it's less work and moving pieces in different repos syncing to when this PR hits various channels if we can combine with this PR, since we have to uplift anyway.

@@ -17,8 +17,10 @@ namespace ntp_background_images {
ViewCounterModel::ViewCounterModel(PrefService* prefs) : prefs_(prefs) {
CHECK(prefs);

// When browser is restarted or component is updated, we reset to "initial"
// count.
count_to_branded_wallpaper_ =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have to reset this value from ViewCounterModel::Reset().
It's called whenever component is updated.

registry->RegisterBooleanPref(
prefs::kBrandedWallpaperNotificationDismissed, false);
registry->RegisterIntegerPref(
prefs::kCountToBrandedWallpaper,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we delete prefs::kCountToBrandedWallpaper, it would be good to clear it from Preferences file.
We usually do this from brave::RegisterProfilePrefsForMigration().

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed via 22c14c5

#include "brave/components/ntp_background_images/browser/features.h"
#include "brave/components/ntp_background_images/common/pref_names.h"
#include "components/prefs/pref_service.h"

namespace ntp_background_images {

namespace {

constexpr base::TimeDelta kCountsResetTimeDelay = base::Days(1);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be great to have this configurable via Griffin, so that if the value needs changing in the future we do not need to wait for the trains

@simonhong
Copy link
Member

I pushed another PR #19896.
As this PR will set zero to kInitialCountToBrandedWallpaper at startup,
brave/brave-browser#32359 could be happened more frequently.
It would be good to handle it before merging this PR.

@simonhong
Copy link
Member

Found another NTP issue(brave/brave-browser#32577) and I think it also could happen easily after this PR merging. Pushed #19915.

@lukemulks
Copy link

Hi @petemill @tmancey @simonhong do we have an eta for when this is likely to be committed? I'd heard we were aiming for the release this week, but it looks like this is still in progress. Asking so I can give sales team an update on this too. Thanks.

@lukemulks
Copy link

Hi all, apologies for the bump, but wanted to follow-up on my prior note above from last week. Thanks @tmancey @petemill @simonhong

@simonhong
Copy link
Member

I left some trivial comments but this PR looks good to me except that.

@lukemulks
Copy link

@tmancey @petemill given @simonhong comment above, can we please prioritize getting this committed and merged? Team is pretty eager to get a read on potential volume increases with some large customers deploying campaigns over the next two weeks. Thanks!

@petemill
Copy link
Member Author

petemill commented Sep 25, 2023

Sorry @lukemulks, I missed the countless notifications somehow. And as far as I can tell, we decided to not do some of this:

  1. Change post-install first-run count from 2nd to 1st.
    • we should not do this anymore
  2. Change regular interval count from every 4 NTP view to every 3.
    • We should still do this one, though we can do it without this PR via griffin already
  3. Reset the counter every 24hr or browser restart to the post-install first-run count.
    • If we aren't doing (1), then maybe we shouldn't do this one anymore. This would help for the users who are at 2 more NTP views to go before the NTT will show, as it will reset them to 1 more NTP views to go. However, for the users who are at 0 more NTP view to go before the NTT will show, we would be adding a delay of 1 extra NTP view which they wouldn't have had previously.

The argument for keeping (3) despite also keeping initial NTT count to the second NTP view is that it ensures that users: a) see at least one NTT on the second NTP each day and b) have their first NTP of the day be not a NTT. So the improvement over only implementing (2) is that users who only open 2 NTP a day will always see 1 NTT. If we don't implement (3), then those users will see 0 NTT.

Since this is a test to see the effect, I'm inclined to suggest we keep (3). Just want to make sure we're clear where we're landing as there were a few opinions.

EDIT
I mitigated the issue somewhat by using the minimum of the initial count or the current count so that when new NTT data is received or the 24hr timer expires, we don't lose the NTT view if the user was already scheduled to see a NTT on the next NTP.
This PR is now ready IMO.

@petemill petemill requested a review from a team as a code owner September 25, 2023 06:56
Copy link
Member

@simonhong simonhong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++

Copy link
Collaborator

@mkarolin mkarolin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chromium_src++

@lukemulks
Copy link

Thanks @petemill agree on keeping item 3 for purposes of testing. Thanks!

@lukemulks
Copy link

@rebron @tackley per ads gtm call - ntt test changes ^^

Copy link
Collaborator

@bridiver bridiver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chromium_src changes ok

@petemill petemill merged commit 3c5e87d into master Sep 27, 2023
15 checks passed
@petemill petemill deleted the ntp-si-initial-count-update branch September 27, 2023 05:38
@github-actions github-actions bot added this to the 1.60.x - Nightly milestone Sep 27, 2023
@lukemulks
Copy link

Thank you all for the team effort getting this through. Much appreciated 🫡

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants